Я первоначально позаимствовал из документации на:

Kieback & Peter
Siemens Synco
Danfoss ECL
Regin Corrigo

Постоянно приходится доводить до ума и дописывать всякие "фишки".

А Вы?

Первоначально ознакомился с алгоритмом защит приточек, видел, что и как сделано в разных вариантах и у разных производителей. Когда занялся "писательством" проанализировал уже разработанную на фирме до меня программу. Когда сравнил ее со своими представлениями то сел и написал свою версию, которая с тех пор в постоянном совершенствовании и корректировании на практике. Интересные идеи по крупицам подбираю в описаниях, на выставках, в рекламах.
В принципе, мне очень помогло знание традиционного программирования и умение составлять, изготавливать и отлаживать "железные" цифровые устройства. По алгоритмам самих процессов - общение с коллегами.

Самый интересный алгоритм, имхо, у ECL, его я брал за основу с незначительными изменениями.

При создании программ брал за основу изделия Овена серии ТРМ (1, 12, 32, 33) и САУ МП - как, в своё время, наиболее мною изученные и не вызывающие нареканий в части реализации алгоритмов. Конечно, в ПЛК они обростали всякими дополнительными функциями, которые до этого реализовывались при помощи релейной автоматики или дополнительных устройств. Или не могли быть реализованы в принципе.

Landis & Staefa RWI65
Штука очень древняя (пра-прародитель Siemens Synco, если я правильно понимаю), но все основные алгоритмы там есть. И документация весьма подробная.

Я изначально брал из ТЗ.

Алгоритмы то же в ТЗ расписывали?

Конечно. Технологию пишет технолог, а я реализую. ТЗ очень важная бумажка, которая разграничивает ответственность. Ведь понятие "сделать автоматику" весьма расплывчатое. Один производитель делает защиту от падения температуры теплоносителя, а другой нет. Один делает защиту от пропадания фазы, а другой нет. И так по сотне ньюансов. Чем больше защит, выше функционал, тем выше цена. Вот в этом то и противоречие. И когда заказчик пытается кроить, технолог в ТЗ должен отразить, что делаем, а что кроим. Заказчик сие подписывает. И если потом оборудование крякнуло, а нужной защиты не оказалось, то ТЗ четко расставляет точки над i, и не позволяет искать крайнео вольно толкуя когда то кем то и что то сказанное. Открываешь и читаешь: "выполнить так то и так то, с защитой от того то... предусмотреть управление с того то и ДУ контроль за рабочими параметрами..." А технология вообще святое. Что в каком случае открыть, на сколько и когда закрыть.

Заказчик способный выдать такое ТЗ существо того-же попрядка, что и "идеальный газ"

Странно, что вы не понимаете этого вопроса. Я же писал, что ТЗ на АСУ выдает технолог, а не заказчик. Заказчи в некоторой роли определяет вам интерфейс работы с системой, например панель оператора на щитах, нужна ли диспетчеризация, сколько АРМов и места их размещения. Нужны ли удаленные АРМы... А технолог вам пишет алгоритмы и параметры. Неужели вы на себя берете ответственность за правильность придуманного вами алгоритма? Алгоритм работы котла мне к примеру дает производитель котла. По вентиляции, отоплению и водоснабжению у нас есть технологи...

ОООО!!! КОЛЛЕГА !!! Вы затронули "тонкую материю психоЛОХИИ" тупого ЗАКа, Ваш долг , право же святой - подсказать, направить на пусть истинный его ибо обряшет он веру в Вас да закажет Вам сполна ...

В большинстве случаев именно так и происходит.

Это печально.

Не забываем, что ответственность - это деньги.
Чем больше ответсвенности берется, тем больше денег получается.
Ответственности нет - соответственно оплачивается только труд программиста по расценкам.

Вы забываете о том, что знак у суммы может быть разным, как плюс, так и минус. Если алгоритм сочиняет программист, а не технолог оборудования, то ничего хорошего из этого не получится. Ка вы придумаете алгоритм гибридной системы вентиляции с центральной секцией охлаждения и 4 трубными доводчиками, не видя расчетных айди диаграм? Все параметры системы расчитывает программист??? Ка вы расчитаете задание центральной приточки, зная задания на фанкойлах? А на какое время будете минимально включать ККБ??? А минимум на какое отлючать??? Ведь у каждого оборудования эти параметры разные. Есть и компрессоры с переменной производительностью, а есть спиральные... Программист всего этого знать не может. А если взять параметры котла, то откуда их знает программист???

Ну во первых есть паспорта на оборудование, во вторых программист может иметь технологическое образование =)

Не забываем, что алгоритмы пишет не только программист.
1. У меня алгоритмы пишет Инженер по автоматике. (именно так - Инженер с большой буквы).
Да, он не технолог, но в общем виде представляет себе процессы обработки воздуха по i-d диаграмме.
И не просто представляет, а знает как они работают, ибо занимается в том числе пуско-наладкой,
т.е. на себе ощущает, как работает его алгоритм.

2. Естественно, в первом приближении ставятся какие-то (или из ТЗ или из опыта) значения "по умолчанию".
Естественно, в процессе наладки они корректируются "с учетом местных условий".

Опыт. Далее см. п.2.
3. У меня есть пример, как программист "нарисовал" мнемосхему приточки на диспетчерской. Показать ?
Кстати, а интерфейс диспетчерской тоже берете из ТЗ. Интересно как это прописывается ?

Водитель грузовика сдает назад, напарник ему помогает:
- Давай-давай, левее!.. Еще-еще!.. Теперь правее!.. Давай-давай, сейчас пойдет!.. Еще!... Стоп! А теперь, выйди и посмотри, что ты тут натворил!

Интересненькая тема... Я бы тоже не взялся писать программу контроллеру, управляющему технологическим процессом, не зная самого процесса... как минимум - нужно знать взаимозависимость сигналов с датчиков и управляющих сигналов... Но мне проще... насосы повышения давления, взу, кнс, циркуляции - как правило имеют типовой алгоритм... иногда приходится по месту менять пару уставок в целях достижения оптимального режима... а как тока че нить посложнее - дай тз, нафик мне голову ломать... тут и тз такие дают, что крыша едет, а обратишся за пояснениями - в ответ: "Да забей, че паришся, сделай как нибудь..." Нафик...

Просто в этом случае приходится самому изучать сам процесс. Так, например, три года назад я стал специалистом по технологиям сжигания древесных опилок в котлах-утилизаторах, год назад освоил технологию пропаривания железобетонных изделий, а сейчас изучаю микроклимат теплиц. Это всё ведь довольно просто... Нафиг, говорите? А по-моему - это интересно... Именно этим мне и нравится моя работа.

Интересно, если адекватно оплачивается или, как минимум, перспективно... а парить мозх над решением самому Заку ненужной задачи, да еще и в случае неудачи выслушать что именно ты во всех бедах виноват... неее... эт мы проходили...

ЗЫ. Были объекты, на которых я переписывал абсолютно безплатно программы в контроллерах стоящих в шкафах конкурентов, киданувших этого Зака... но там хоть это нужно было _людям_... а очень нередко нарываешся на заказ, в котором заказчика не интересует НИЧЕГО, кроме отката... и ему все твои гениальные решения и безссонные ночи по большому барабану...

Да все, что вы перечислили, это мелочи, которые я и сам прекрасно знаю. Но речь то в другом. Оборудование разных производителей имеет свои особенности. Для ясности приведу примеры:
1. Большинство вентиляторов и насосов имеют выходные контакты термореле. Но некоторые при этом сами отключают электродвигатель от нагрузки, а другие нет. И если в первом случае можно не париться с отключением при перегреве, а только сообщить на АРМ, то во втором случае надо отключить нагрузку.
2. У разных ККБ секций охлаждения разные схемы включения и алгоритм подачи сигналов.
3. Одни производители пластинчатых рекуператоров рекомендуют отслеживать замерзание оного по реле-давления, а другие по разнице температуры воздуха на входе и выходе его. А какое давление на реле-давления ваш инженер с большой буквы поставит, если пуск он осуществляет летом, и проверить срабатывание при замерзании нет возможности? А какую разницу температур? А какие условия он забьет в алгоритм, что бы система поняла, что рекуператор оттаял? Если ошибется, то про рекуператор зимой можно забыть, да и двери какие то не закроешь, а какие то не откроешь.

Пока хватит примеров?



Да зачастую нельзя что попало ставить, да и не откорректируете вы. Зачастую если вы нашли порог, то оборудование уже нужно менять. Ну и какой допустимый перепад давления на котле он выставит? А какой минимальный расход теплоносителя через котел при 50% мощности? А при 70%? А какова минимальная частота работы насоса? А максимальная? А какое максимальное давление допустимо в системе? А можно ли сразу включить котел на полную мощность, или с полной мощности выключить? А если нет, то как его выводить на максимальный режим? Сначала на 10% или на 50%? А сколько времени греть? А мощность плавно наращивать или через определенное сразу можно 100%? Все эти вещи может знать только производитель оборудования, и вы это должны получить в ТЗ. Не вздумайте это все сочинять. Добром не кончится, и огромная сумматочно будет в минусе.


Да я таких схем полно выкладывал. Интерфейс диспетчерской прописывается в количестве экранов, сигналов и органов управления. Сами мнемосхемы берутся со схем проекта в упрощенном виде.


Если у вас нет работы и вам больше нечем заняться, то можете. Однако как и где вы сможете найти ответы на вопросы, описанные мной выше?

Во-первых, лучше сделать унифицированную схему и отключать даже то, что само отключается.
Во-вторых, само отключается только на слабых однофазных движках.
В-третьих, вы правда видели технолога, который разбирается в термоконтактах двигателя ?
Расход, напор и присоед. размеры - вот все, что их интересует.
Максимум, что они могут сделать - отправить к документации.

Аналогично, ни один технолог вам этого не скажет.

Ну вы-то должны понимать, что ВСЕ пластинчатые рекуператоры устроены одинаково.
И то, что производители рекомендуют разное - есть мулька.
Только практикующий инженер может сравнить эти варианты, выбрать оптимальный и далее его использовать.

Как правило, пусконаладка осуществляется на всех режимах работы - зима, лето, переходный.
Поэтому летом настраивается лето, зимой - зима, а весной или осенью - переходный.
Неужели Вы уверены на 100%, что написанная по ТЗ программа с выставленными "по умолчанию" параметрами, сразу приведет к безотказной и оптимальной работе установки ?
Без наладки ?

P.S. За котлы не брались и пока не беремся.

Да в том то и дело, что технолог подбирает оборудование и в ТЗ включает все его параметры и описание. Мне не требуется ничего искать. Технолог подбирая ККБ разумеется знает особенности его работы и алгоритм подключения. Это технолог знает марку и тип компрессора, а значит и его технологические особенности, он знает тип фреона и его особенности, знает давления, таймауты и температуры, а так же знает процесс по диаграммам и пишет вам когда и до чего холодить, а когда ичто то блокировать и греть.


Параметры, которые вы называет "по-умолчанию" достаточно точные и получены на примерах других объектах или расчетах. Крайне редко что то меняется потом при наладке. и если я приточки с рекуператором пустил летом, то не караулю там зиму. Как правило и зимой оно работает. Отвечает за это именно технолог. Я отвечаю лишь за правильность исполнения ТЗ.

"Да в том то и дело, что технолог подбирает оборудование и в ТЗ включает все его параметры и описание. Мне не требуется ничего искать. Технолог подбирая ККБ разумеется знает особенности его работы и алгоритм подключения. Это технолог знает марку и тип компрессора, а значит и его технологические особенности, он знает тип фреона и его особенности, знает давления, таймауты и температуры"

"Я отвечаю лишь за правильность исполнения ТЗ. "


Везет же людям.

Это опять "идеальный газ"

Возможно вы правы, но кто как не мы должны стремиться приблизить ситуацию к идеалу?

Такая специальность называется "кодер", а не программист, не инженер, не специалист. В таком случае, это всего лишь протез с голосовым управлением между технологом и контроллером. И в таком случае, вероятнее всего, технологу будет просто проще, спокойнее и увереннее за результат сделать все самому.
Это как в автобусе - если я начну водителю говорить, где притормозить, кого пропустить, куда повернуть, что означает каждый знак, то мне проще самому сесть за руль.

Вы хотя бы в классификатор всеросийский глянули, что ли. Никакого "кодера нет". Вы вдумайтесь в смысл слова ПРОГРАММИСТ. Когда в ВУЗе преподают программирование, то рассматривают совместную деятельность ПРОГРАММИСТА и ЭКСПЕРТА. Если вы учились программированию, то должны знать это. Эксперт знает предмет программирования, а программист является "переводчиком" с языка эксперта на язык машины. Программист не является дипломированным или сертифицированным специалистом ни в теплотехнике, ни в хладоснабжении, ни в машиностроении. Я конечно понимаю, что зачастую человек занимающийся программированием прекрасно разбирается во многих алгоритмах, но возложить на него ответственность за работу всей системы не верно. Я сам частенько помогаю написать ТЗ вместе с алгоритмом, и часто вношу неожиданные предложения, которые с удовольствием принимаются технологом. Но ТЗ обязательно должно быть, как документ, подписанное и технологами, и заказчиками, и генподрядчиком. Это та самая главная бумага, которая отвечает на вопрос, что мы и как делаем, и что в конечном итоге должно получиться. Она об этом говорит и заказчику, и технологу, и монтажникам, и программисту... всем. Если этой бумаги нет, то сто раз будешь переделывать. Заказчик потом захочет что то изменить, что то переделать... за ваш счет.

Согласен полностью. При спорных вопросах ТЗ ооочччееень выручает... Соответствует работа узла ТЗ с Вашей подписью? Соответствует... Нравится? Не нравится? Денех дай, переделаем... Вопрос даже не в деньгах, как таковых, вопрос в разграничении ответственности.

Эти откаты меня уже задрали! Что за народ, только на лапу давай, а что уже там сделаеш - заказчику нас**ть.

А вы старайтесь полюбому продвинуть\пропихнуть качественное изделие, максимально надежное и технологичное... тогда неприятный осадок от отката компенсируется профессиональной гордостью. Хотя бы.

Если будет позволено высказаться ПРОФЕССИОНАЛЬНОМУ ПРОГРАММИСТУ... ТЗ - это ТЗ, я в этот документ даже не смотрю - он меня не касается.
Есть ГОРАЗДО более важные документы - ПОЯСНИТЕЛЬНАЯ ЗАПИСКА и Программа испытаний. Еще один ВАЖНЕЙШИЙ документ - Технологическая карта процесса - в АВОК не используется. Этот документ "распылен" в ТЗ и Пояснительной записке. Я, безусловно, хорошо разбираюсь в физике процессов АВОК (инжненр-физик, все-таки), но это для себя, а так -это дело проектировщиков. Мое дело - воплотить идеи их (проектировщиков) в жизнь, что само по себе не очень простое дело . Конечно, я высказываю свои пожелания, некоторые учитываются...
Программист (кодировщик - это другое) - ДОЛЖЕН не обсуждать техкарту, а РЕАЛИЗОВАТЬ ее на имеющихся (выбранных не им!!!!) средствах.
Я автоматизировал много разных производств, имею представление о многих техпроцессах - но подменять собой ТЕХНОЛОГА - да ни за что.
КАЖДЫЙ ДОЛЖЕН ЗАНИМАТЬСЯ СВОИМ ДЕЛОМ !!!

Полностью согласен, лишь с одной оговоркой... Иногда случается так, что программист разбирается в задаче более глубоко, нежели предоставленный заказчиком "технолог"

спорите о ерунде какой-то. ведь козе понятно, что в ХВАКе ситуёвина такова, что тот, кто составляет алгоритм работы оборудования, тот и есть по сути своей и технолог и проектировщик в одно лицо. те же, кто умеет щитать сопротивленья воздуховодов, теплоизбытки, снипы и прочую чепуху всего лишь вспомогательное оборудование для проектирования.
щютка, но с долей юмора.

Согласен, простое раздутие слона из пальца…

На самом деле всё типовое и работает одинаково с разными параметрами естественно.

PS: У всех видов утилизаторов тепла, один и тот же алгоритм работы, и используется одно тоже количество датчиков!
Если используете датчик перепада давления (диф. манометр), то он Вам и покажет, что ротор уже обмерз, а с помощью датчика температуры за ротором, можно предотвратить его обмерзание .

Да, абсолютно верно. Вообще у датчиков-реле перепада давления разрос уставки срабатывания гуляет в интервале +-20 Па, так что окромя как засор фильтра показывать и работу вентилятора - т.е. сигналы "некритичные" к фактической уставке давления, больше они ни на что не годны. Обмерзание же рекуператора может весьма плачевно отразиться на системе, поэтому лучше тут использовать датчики темпратуры.

Да, в принципе "нет ничего нового под Луной". Но реальные системы отличаются друг от друга... например, логика работы и взаимодействие с ИТП систем, заполненных этиленгликолем и водой разные. Те же ИТП и приточки на воде. куча нюансов. Например, переключение насосов, подключение приточек и "просадка" температуры. "Горячее" резервирование приточек, быстрый их вывод на режим. "Экономия" по обратке в ИТП.
Вообщем, каждый проект уникален (в моей практике). Тут без помощи проектировщика (технолога) не обойтись. А если дело касается "инженерки"
в более общем понимании (свет, автостояники со светофорным регулированием, взаимодействие с СКД по экономии) - то тут вообще программисту без подробного описания технологии - "труба".

Мнения разделились, ну что же и я тогда внесу свою лепту. А делаю так - если сфера деятельности мне не знакомая, то без "одобрямса" технолога я ни шагу, если же я в этом понимаю достаточно (по крайей мере так я думаю ) то максимум консультацию у эксплуатации и (или ) технолога ( типо "как привыкли?", "как раньше дела обстояли?", "а чего бы хотели?"... ), что то навроде анкетирования провожу чтобы расставить точки над "i" Хотя могу и не "вдаваться в дебри .

Но при - этом логика та же, только параметры разные

P. S. Свет, светофоры - ни чего сложного не вижу, есть сценарии работы и программисту в прицепе нужно разбираться с логикой, а не писать программы для серьезных вычислений, да и речь вроде не про это была!

Повторюсь - я встречал несколько типов приточек в проектах. Энергосбережение приводит к тому, что проект становится очень сложным, т.к. программисту надо выяснять алгоритмы этого сбережения и учитывать кучу ТЕХНОЛОГИЧЕСКИХ нюансов работы всех систем здания.

Главное - объяснить это заказчику. Программист поймет это после выдачи смачного пинка и соотвествующей литературы. Я сижу на одной автоматизации вентиляции и самое сложное что я видел - это вентиляция особо чистых помещений. Все энергосбережение в отечественных проектах для приточно-вытяжной установки обычно упирается в применение ЧРП в так называемых система "вентиляции по запросу" и рекуператоров. При этом для вентиляции "по запросу" проект вентиляции (а не автоматизации!) должен иметь соотвествующий вид, о котором старые пердуны в проектных институтах да же не догадываются. Вот и остаются рекуператоры, а для них алгоритм один с небольшими дополнениями. Про VAV системы да же говорить не хочется, особенно после того, как инженера по вентиляции тебе задают вопрос "Что-то такое слышал... А что это такое?".

Заказчику, как првило, "до балды" как реализовано ТЗ. Но есть еще такая штука, как аудит (столкнулись с этим). Пример. В ОЧЕНЬ навороченном
здании (цена вопроса - цифра с многими нулями) есть бассейн. Нужен климат-контроль (Т, влажность). В установке есть ВСЕ (рекуперация, рециркуляция, два контура водяного подогрева, контур водяного охлаждения). Энергосбережение - МИНИМАЛЬНОЕ использование холодильной машины (при наличии гортепла), но баланс при использовании электрокотлов. Без ТЕХНОЛОГИЧЕСКОГО обоснования работы системы и использования в программе результатов РАСЧЕТОВ работы системы - пипец, т.к. нужно ОБОСНОВАНИЕ реализованного в ПРОГРАММЕ проекта.
Без участия технолога систему не сдать, причем технолог отвечает на вопросы как по выбору алгоритма работы установки (обеспечение требований ТЗ), иак и на вопросы по выбору алгоритма энергосбережения (расчеты). Во как.

Это уже не простая задача, а можно сказать: комплексная. И за это деньги, причем плотят. Ранее, я писал о большинстве применяемых вентиляционных установок...
Хотя в вашем случае, программеру нужно добиться максимального КПД утилизатора тепла, тем самым, уменьшить расход тепла на 1 и 2 подогреве, вот и вся экономия

Не знаю, как большинство. я участвую в проектах, где платят много, но требуют много. Насчет утилизации тепла - так я и пользуюсь РАСЧЕТАМИ,
(например, при выводе системы на режим). Алгоритмы типа(предпрогрев до фикс. Т, затем ПИД - это АНАХРОНИЗМ , простите за резкость).
Хотя, как опция, включен в алгоритм (для особо упертой Службы эксплуатации). Формулы для расчета параметров я получаю от технолога (Пояснительная записка). Аналогично и алгоритмы энергосбережения. А уж как это реализовать на техсредствах - это моя забота - мне за это деньги платят. Хотя, признаюсь честно, задумки технологов иногда ставят меня в тупик - тогда и ищется компромисс и вносятся поправки в проекты (иногда и в текущий проект - но редко).

Хммм... Это Вы про секцию нагрева написали? Если Вам не трудно, напишите, как по Вашему должен этот алгоритм выглядить... Отбрасывая "хитроумные" защиты от опнижения температуры обратки, прогрева в зависимости от температуры наружного воздуха, ограничения подачи воздуха при низких наружных температурых - максимум что я встречал это переключающийся ПИД.

Может, поделитесь, типа алгоритмами как это они у Вас реализованы? Очень интересно, что Вы используете вместо ПИД?

To Nick

Имея практический опыт, скажу - подобное упрощение не приведет к желаемому результату.
Для максимальной оптимизации нужно учитывать больше факторов и все процессы на i-d-диаграмме, а не только теплоутилизации.

to Nick
Алгоритмами не поделюсь - однозначно. Они разрабатывались с помощью фирмы, принадлежат фирме. Используется гибрид ПИД и нечеткой логики.
ПИД - специфический.
to Abysmo - "хитрые" примочки - это 75% успеха. Честно говоря, ничего "хитрого" в нет изначально - это нормальное окружение для вывода на режим. Просто без них очень некомфортно.

Соглашусь, но, по-моему, i-d-диаграмма, нам больше помогает при режиме осушения!?


Нечеткая логика - это хорошо, но смысл, если обычный хорошо отстроенный ПИД вполне справляется со своими задачами в HVAC!?